Shareware Grab Bag/Shareware Grab Bag.iso/011/emc110.arc/EMC110.DOC

Text File | 1987-07-01 | 14.5 KB | 279 lines

                        EXPANDED MEMORY DISK CACHE 1.10


1. Introduction.

     EMC110.COM is a program designed to cache IBM-XT/AT hard disks in LIM
(Lotus-Intel-Microsoft) expanded memory; it will not cache floppies, nor will
it cache in DOS memory or AT extended memory.  It should work with any system
which has a LIM-spec expanded memory board and software, a disk system which is
IBM-XT/AT-compatible at the ROM-BIOS level, and NO OTHER STORAGE DEVICES.  If
your system does not clearly fit this description --- in particular, if you
have a hard disk system which exceeds the 32-meg DOS limit, or if you have any
removable-media storage devices other than standard floppies --- you should NOT
use this program without first reading the 'Technical Notes' section below.


2. Installing the Cache.

     The cache can be installed by typing

                              EMC110 [max [min]]

at the DOS prompt, where the optional parameters 'max' and 'min' are the
maximum and minimum number of expanded memory pages you wish to use for the
cache (each page is 16K).  If 'max' is not specified it defaults to 512.  The
point of specifying 'max' is to prevent the cache from consuming all available
expanded memory.  If 'min' is not specified it defaults to 1.  The point of
specifying 'min' is to prevent the installation of a cache which is too small
to be effective.  Note that the parameters are positional: if you want to
specify 'min', you must specify 'max' first.

     If at least 'min' pages of expanded memory are available, EMC110 installs
itself as a resident program which, subject to the constraint of 'max', uses as
much expanded memory as possible and up to 64K of DOS memory.  Specifically,
the program requires approximately 3K plus 128 bytes per expanded memory page
used.  Thus a 1-meg cache uses about 11K of DOS memory and, if you have enough
expanded memory, a cache of nearly 8 meg should be possible.


3. Changing the Cache Size.

     If EMC110 is already installed, the cache size can be dynamically changed
by typing

                              EMC110 [max [min]]

at the DOS prompt, where 'max' and 'min' have the same significance as for the
initial installation.  The result is that the cache is purged, all expanded
memory being used by the cache is released, a new allocation of expanded memory
of the appropriate size is obtained, and the cache is reinitialized.  Since no
reallocation of DOS memory or manipulation of interrupts is involved, the cache
can be resized under circumstances which would not permit removing it and
reinstalling it.  However, since the cache retains its original allocation of
DOS memory, this imposes an additional constraint on the maximum cache size in
addition to 'max' and the amount of expanded memory available: the new size can
never exceed the size of the original installation.


4. Disabling the Cache.

     If EMC110 is installed, it can be disabled by typing

                                   EMC110 X

at the DOS prompt.  The result is that the cache is purged, all expanded memory
being used by the cache is released, and subsequent BIOS disk interrupts are
immediately passed on to the prior interrupt handler.  However, the cache
maintains its allocation of DOS memory and its position in the BIOS disk
interrupt chain, so it can be reactivated as described under 'Changing the
Cache Size' above.


5. Uninstalling the Cache.

     If EMC110 is installed, it may be possible to uninstall it (i.e., remove
it from memory entirely) by typing

                                   EMC110 XX
or
                                   EMC110 XXX

at the DOS prompt.  The 'XX' variant will complete the uninstallation only if
it can be done without fragmenting DOS memory.  The 'XXX' variant will complete
the uninstallation whenever possible.  If EMC110 was not the last program to
insert itself in the BIOS disk interrupt chain, then the uninstallation will
not be possible.  If the uninstallation is not completed, then the cache will
be left in the disabled state.


6. Querying the Cache.

     The status of the cache can be determined by typing

                                   EMC110 ?

at the DOS prompt.  The result, in addition to an identifying banner, will be
the display of either

                              Cache not installed
or
                           xx page cache installed.

If the cache is installed, but has been disabled or resized to less than its
original installed size, then either

                               Cache is disabled
or
                            xx page cache is active

will also be displayed.  In addition, if any disk read, disk write, or expanded
memory errors have occurred, further lines will be displayed detailing these
errors.  Note that the error counts are not reset by resizing or disabling the
cache.  Moreover, only errors which arise from disk or expanded memory requests
issued by the cache itself are counted.

     The display described above is also produced by all other calls to EMC110
which don't result in removing the cache from memory entirely.  The difference
is that, whereas the other calls result in the cache's being reinitialized, the
'?' variant leaves the cache intact.


7. Compatibility with Resident Program Managers.

     EMC110 should not be used with any program which claims to be able to
suspend and later reactivate resident programs.  All disk caches work by
keeping copies of disk sectors in memory.  If a cache is suspended and later
reactivated by another program, the cache has no way of knowing that its
contents may no longer be correct.  The results could be disastrous.

     EMC110 may also be incompatible with programs which merely uninstall
resident programs.  Such programs presumably work by recording the computer's
state before a resident program is installed, and restore that state when
uninstalling it.  If you use such a program to uninstall EMC110, or if you
never use EMC110 to resize, disable or uninstall itself, this technique should
work.  But consider the following scenario: first you install EMC110, then you
install resident program 'A', then you disable EMC110, then you install
resident program 'B' which allocates some expanded memory, then you reactivate
EMC110.  At this point the expanded memory owned by EMC110 is probably not the
same as it was when 'A' was installed, so simply removing 'A' and 'B' from
memory and restoring the computer's state to what it was when 'A' was installed
will not work.  Admittedly this scenario is unlikely, and some resident program
managers may even be clever enough to cope with it, but the integrity of your
hard disk is at stake.  If want to use both EMC110 and a resident program
manager, the safe way is never to use EMC110 to resize, disable or uninstall
itself.


8. Compatibility with Multitasking Programs.

     EMC110 doesn't work with DoubleDOS 4.0.  It does appear to work with both
Microsoft Windows 1.03 and Desqview 1.3 and 2.0.  In fact the resize and
disable features work in a Desqview window.  But note that EMC110 must be
installed BEFORE you invoke Windows or Desqview; you should NEVER install
EMC110 in a window.


9. Operational Notes.

     EMC110 is a pure write-through cache.  Both reads and writes are cached in
the sense that, whenever an actual disk read or write occurs, copies of the
sectors involved are placed in the cache.  But whereas read requests are
serviced from the cache contents rather than the disk whenever possible, write
requests are always passed on to the prior interrupt handler.  Unlike most
commercial caches, EMC110 doesn't try to avoid writing to disk by checking if
the data to be written agrees with the cache contents.

     A cache performs like an automatic RAM-disk.  A cache is more convenient
than a RAM-disk in that you don't have to copy files to it, you don't have to
delete old files to make room for new ones, and you don't have to remember to
copy updated files back to disk.  On the other hand, a cache is slower than a
RAM-disk, and writing temporary files to disk is a waste of time.

     Both caches and RAM-disks provide increased performance by decreasing the
time required to locate data (the seek time) and the time required to transfer
it.  Whether there is a significant improvement in transfer time is highly
system dependent; on a system with a slow processor and a fast disk system
there may be no improvement at all.  But RAM-disks eliminate seek time
entirely, and caches usually reduce it dramatically.  Whether there is a
significant improvement in overall system performance depends on what you're
doing.  If your primary activity is word-processing, all you'll get is a
psychological lift from seeing the program load faster.  But for disk-intensive
activities like sorting a huge fragmented database, the improvement should be
significant and, if the files involved are too large to fit in a RAM-disk, a
cache is your only choice.

     One factor in the performance of a cache is its size.  The smaller the
cache the less likely it is that a read request can be serviced from the cache
contents.  If the cache is too small, then the time spent copying each newly
accessed sector into the cache (replacing previously accessed sectors) may
exceed the time saved by occasionally finding the desired sector in the cache.
The result will be a degradation rather than an improvement in performance.  On
the other hand, the larger the cache the longer it may take to find a sector in
it.  Ideally the cache should be just large enough to contain all the sectors
that are currently being accessed, but using an unnecessarily large cache is
preferable to using one that is too small.

     As you use EMC110, you may find that the cache doesn't always contain
everything that you think it should.  There are two reasons why such behavior
may be consistent with correct operation of the program.  First, the cache may
be too small.  Second, EMC110 organizes cached sectors into groups, and its
response to any error or unexpected condition is to purge either the group
involved or the entire cache.  So a disk error may result in seemingly
unrelated sectors being purged from the cache, even though the sector causing
the error may get into the cache on a retry.  Similarly, since EMC110 treats
any request except read, write or status as an "unexpected condition", any such
request will cause the entire cache to be purged.


10. Technical Notes.

     EMC110 works by intercepting calls to interrupt 13h.  It assumes that the
calls it intercepts and passes on can be interpreted as calls to the IBM-XT
hard disk BIOS, i.e., that the contents of the processor registers have the
significance described in the IBM-XT Technical Reference Manual.  In particular
it assumes that if the high bit of register DL is 1 then the call is directed
to a hard disk.  It also makes three assumptions that are not explicit in the
Technical Reference Manual description, namely that all hard disks have non-
removable media, that all hard disks have 512-byte sectors, and that multi-
sector requests are serviced by incrementing the sector number, the head number
and the cylinder number, in that order.  If your system contains storage
devices other than standard XT/AT hard disks and floppies, you must determine
whether their operation involves interrupt 13h and, if so, whether the above
assumptions are valid.  If they're not, the use of EMC110 will produce
disastrous results.

     EMC110 also uses the drive-parameters subfunction (AH = 8) of interrupt
13h for two purposes of its own.  First, it uses this subfunction at
installation time to determine how many sectors per track and how many heads
each hard disk has; it will not cache hard disks which are not reported by this
subfunction.  Second, communication with an installed copy of EMC110 is
implemented in part by requesting parameters for a non-existent hard disk.  If
EMC110 is not installed the result should be an error return.  If your hard-
disk BIOS is willing to return parameters for a non-existent disk, no harm
should be done; EMC110 will simply refuse to install itself.

     Except for this non-standard use of the drive-parameters subfunction,
EMC110 expects requests for only three subfunctions of interrupt 13h: status
request (AH = 1), read sectors (AH = 2), and write sectors (AH = 3).  A request
for any other subfunction is handled by purging the cache and passing the
request on.

     EMC110 is not re-entrant.  Its correct operation depends upon the fact
that, since the IBM disk BIOS is not re-entrant, no operating system, multi-
tasking program, or interrupt-driven program dare permit two concurrent calls
to interrupt 13h.  This fact is also the reason for implementing communication
with an installed copy of EMC110 by making non-standard use of interrupt 13h
rather than by using a more respectable method.


11. Copyright, Disclaimer, etc.

     EMC110 is copyrighted by the author.  However, the author hereby grants
permission for anyone to use this program, and to distribute it freely in
unmodified form along with this documentation for no more than a nominal media
charge.

     The author makes no claim about this program except that he has done
everything he could think of to ensure that it is error-free, and that he's
using it himself.  If you use EMC110, you do so with the understanding that
even the most carefully written program may contain subtle errors that appear
only after prolonged use, that any resident program is subject to corruption by
other ill-behaved programs, and that either of these eventualities could result
in loss of data stored on your disks.

     I'm interested in any comments and suggestions you have to make.  Even if
you don't have any comments or suggestions, it's encouraging to hear from
people who find EMC110 useful.  I'm also interested in reports of systems and
software with which EMC110 doesn't work, but it's unlikely that I'll be able to
help.  While you might be willing to send me copies of the software,
duplicating your hardware would almost certainly be impossible.  I don't return
long distance calls, but I do make an effort to answer all letters that require
a reply.  Please address any correspondence to

                       Frank Lozier
                       Department of Mathematics
                       The Cleveland State University
                       Euclid Avenue at East 24th Street
                       Cleveland, Ohio 44115